Network congestion may occur when more packets or data are transmitted through a network than the network can accommodate. The network typically has a fixed capacity, such as a fixed bandwidth or a fixed packet transmission rate. When more packets need to be transferred than the fixed capacity of the network, the network may employ queues to buffer the packets to accommodate such traffic surges. However, the network elements generally have queues and other resources of a fix size. The network congestion may occur when these fixed sized resources are nearly or fully utilized (e.g., the queues may be nearly full) and are not able to accommodate additional packet transmissions. Conventionally, networks experiencing such congestion may simply drop packets. However, dropping packets may have certain drawbacks, such as causing retransmission of the dropped packets, which may further contribute to or prolong the network congestion.
Explicit Congestion Notification (ECN) is a known congestion avoidance scheme that involves marking packets instead of dropping them in the case of incipient congestion. An ECN-aware network element experiencing incipient congestion may mark ECN fields in headers of the packets to indicate that the congestion is occurring, instead of dropping the packets. By way of example, ECN may use two least significant bits in the DiffServ field in the IP protocol header (IPv4or IPv6) which are assigned to the ECN field to encode four different ECN code-points. An ECN code-point of 00 may indicate not ECN-capable transport (i.e., not ECT) if either end-point does not support, or is not willing to support, ECN-capable transport. Either of two ECN code-points, namely 10 or 01 (ECT(0) and ECT(1) respectively) , may indicate ECN-capable transport (ECT). An ECN code-point of 11 may indicate that congestion has been experienced or encountered (ECN-CE). For example, an ECN-capable node or queue may probabilistically set the ECN field to 11 if congestion is encountered or experienced and then forward the ECN-marked packet. To avoid heavy congestion, routers and other network elements may mark packets with probability depending on an average queue length. Examples of suitable protocols to specify the feedback for ECN include TCP, DCCP, SCTP, and RTP/UDP. The percentage or proportion of packets marked may be indicative of, and directly related to, the level of congestion in the network. In ECN, an end-point receiver of the ECN-marked packets may return feedback or information about the percentage or proportion of marked packets, or the level of congestion, to the sender in order to inform the sender that the network is experiencing congestion. The sender is expected to decrease its transmit rate so that future packets are not dropped. Advantageously, ECN may help to reduce the amount of congestion in the network and the number of packets that are dropped.
Congestion exposure (ConEx) is another congestion avoidance scheme or protocol. Congestion exposure may use and be built upon ECN. Congestion exposure may provide a mechanism that allows a sender to inform the network about remaining path congestion that is expected to be encountered by packets. In ECN the network may signal congestion by ECN marking packets or by dropping packets and the receiver may pass this information back to the sender as feedback. Congestion exposure builds on this by allowing the sender to relay or insert expected remaining path congestion information back into the network to inform the network of this expected congestion. The expected rest-of-path congestion information may be based on or derived from congestion previously encountered by previous packets in the same flow as indicated in the ECN feedback. The network nodes may use this information to estimate how much congestion the flow is likely to cause by sending or forwarding the traffic and may make decisions based on this information. Congestion exposure may provide the information and ability to make flows accountable for the congestion that they cause, or allow to be caused, and may help to manage congestion.
Re-ECN is a known implementation of congestion exposure. Re-ECN is described in the Transport Area Working Group Internet Engineering Task Force (IETF) Internet-Draft entitled “Re-ECN: Adding Accountability for Causing Congestion to TCP/IP,” by Bob Briscoe et al., dated Oct. 25, 2010, pages 1-51. The re-ECN protocol provides a field in each packet so that, as the packet crosses any interface in an internetwork, it carries a truthful prediction of congestion on the remainder of its path.